The following relates to client/server communication protocols. It finds particular application with protocols that allow a document management system to communicate inter-attribute constraints to its clients, and will be described with particular reference thereto. However, it is to be appreciated that the exemplary embodiment is also amenable to other like applications.
Typical networks contain a plurality of devices in communication with each other. In order to facilitate such communication, one or more software components are employed to allow seamless transfer of information and device interoperability. To this end, each device (e.g., a client, a service, etc.) on the network utilized a driver (or similar) to provide particular information to disparate devices. Such drivers were required to be designed for each specific type (model, manufacturer, etc.) of device. Thus, each time new devices were added to a network, a device specific driver was installed to allow communication between the newly added device(s) and the rest of the network.
FIG. 1 illustrates a conventional network architecture 100 wherein a control component 102 interfaces with processing component 1 104, processing component 2 106, and processing component 3 108. In the network 100, the control component 102 is required to include a driver for each processing component with which it interfaces. As known, a driver is a specific type of computer software, typically developed to allow interaction with hardware devices. This usually constitutes an interface for communicating with the device, through the specific computer bus or communications subsystem that the hardware is connected to, providing commands to and/or receiving data from the device, and on the other end, the requisite interfaces to the operating system and software applications.
A driver is a specialized hardware dependent computer program, which is also operating system specific, that enables another program, typically an operating system or applications software package, to interact transparently with the given device. It usually provides the requisite interrupt handling required for any necessary asynchronous time-dependent hardware interfacing needs. Each driver is specific to the attributes of each processing component.
The key design goal of device drivers is abstraction. Every model of hardware (even within the same class of device) is different. Newer models also are released by manufacturers that provide more reliable or better performance and these newer models are often controlled differently. Computers and their operating systems cannot be expected to know how to control every device, both now and in the future. To solve this problem, operating systems essentially dictate how every type of device should be controlled. The function of the device driver is then to translate these OS mandated function calls into device specific calls. In theory a new device, which is controlled in a new manner, should function correctly if a suitable driver is available. In this manner, the driver will ensure that the device appears to operate as usual from the operating systems' point of view.
Conventionally, inter-attribute constraints are hard coded on a client side such that the driver is tightly coupled with the each device. For example, in this embodiment, each processing component 104-108 has a particular driver to facilitate communication with one or more disparate components on a network. Thus, the control component 102 includes a driver 1 110, a driver 2 112, and a driver 3 114. In this example, the driver 1 110 is employed to communicate with processing component 1 104; the driver 2 112 is employed to communicate with processing component 2 106; and the driver 3 114 is employed to communicate with processing component 3 108. An interface component 116 allows a user to communicate with the control component 102.
Requiring a disparate driver for each component on a network is cumbersome and creates communication problems. This problem is exacerbated by the myriad protocols and communication standards required to communicate with a plurality of different models, manufacturers, etc of devices. In addition, different operating systems require different drivers. For example, a driver has to be developed for each operating system utilized by Mac, Linux, and the various instantiations of Windows. Web services technology was introduced in part to alleviate problems associated with specific print driver communication.
Web services are a distributed computing technology that offers interaction and collaboration among vendors and customers to provide computing that is omnipresent. Typically, web services are loosely coupled software components that are delivered over Internet-standard technologies. Conventionally, a web services model follows a publish, find, and bind paradigm. In a first step, a service provider publishes a Web Service in a Web Service registry. Secondly, a client who is looking for a service to meet their requirement searches in a registry. After successfully finding multiple matches, it chooses a service. The client then chooses a service based on its preferences and subsequently downloads the service description and binds with that to invoke and use the service.
One standard concern of Web-based programmers is how to transmit data in an interoperable manner. At the bottom-most layer, an XML standard addresses this. SOAP (Simple Object Access Protocol) is an XML-based mechanism for messaging and RPC (Remote Procedure Calls). It addresses the fundamental problem of firewall traversal in RPC systems by using HTTP as a transport. Thus, SOAP is the protocol used for invoking the service. WSDL (Web Services Description Language) provides an XML-based way of describing a Web Service to provide details of using such service. UDDI (Universal Description Discovery Integration) provides a directory of Web Services, making it easier for clients to discover the services of their choice. The service provider publishes the service description (WSDL) and other searchable details in the UDDI registry. A client uses UDDI to perform the find of a service.
Extensible Markup Language (XML) is an extensible, portable, and structured text format. XML initiative consists of bunch of related standards. Apart from the core XML standard, it includes XSL—Extensible Stylesheet language, which is used to transform XML data into a customizable presentation. XLink and XQuery provide a way to provide flexible query facilities to extract data from real and virtual XML documents on the Web. XPath and XPointer are languages for addressing parts of an XML document.
Utilizing XML involves creating XML documents and consuming XML documents. The creation process involves using editors and tools to create XML documents. On the other hand, consuming XML documents involves parsing the XML documents and extracting the useful data. Creating XML documents is a two step process, which involves 1) defining the grammar and restrictions over data for the XML document and 2) creating the XML document itself.
XML Schemas provides a means of creating a set of rules that can be used to identify document rules governing the validity of the XML documents that you create. Schemas provide a means of defining the structure, content, and semantics of XML documents that can be shared between different types of computers and documents. The XML Schema standard was designed to express object oriented design principles found in common object oriented programming languages into the specification. In addition, XML was designed to provide rich datatyping support similar to the datatyping functionality available in most relational database systems.
What are needed are systems and methods that facilitate comprehensive device communication across a network, wherein client software is device independent.